1. Field of the Invention
This invention pertains in general to computer security and in particular to securing computer databases against code injection attacks.
2. Description of the Related Art
Databases are widespread in modern computing environments. Companies and other enterprises rely on databases to store both public and private data. Many enterprises provide publicly-accessible interfaces to their databases. For example, an electronic commerce web site typically includes a “search” field that accepts search terms and allows an end-user to search items for sale on the site. This search field is a publicly-accessible interface to a database that stores data describing the items for sale.
At a technical level, many of these publicly-accessible databases work by having a web server provide a web browser executing on the client with an HTML and/or JavaScript-based form. The web browser displays this form on the client, and the end-user provides values for the fields in the form. The end-user performs an action, such as pressing a “Submit” button, that causes the web browser to send the entered values to the server. At this point, back-end logic at the server constructs a query to the database using the user-supplied values. This query executes on the database and the server returns the results to the client web browser.
In an SQL (Structured Query Language) injection attack, the attacker fills out the form using specially-crafted data. These data, when used by the server to generate a query to the database, result in a malicious query being sent to the database on behalf of the attacker. The malicious query executes on the database and results in a malicious action.
For example, assume a form asks an end-user for his name and password. A legitimate user might enter “Jim” as his name and “Pickle” as his password. When these values are returned to the server, the server places the values into two variables, for example “name$” and “pass$”. The back-end logic constructs a query using the values of these variables. Assume that the query having the variables is:
Query$=“SELECT*FROM USERS WHERE NAME=‘“+name$+”’ AND PASS=‘“+pass$+”’”.
The back-end logic replaces the variables with the user-supplied values and produces the query:
Query$=“SELECT*FROM USERS WHERE NAME=‘Jim’ AND PASS=‘Pickle’”.
This query, when executed on the database, validates that the end-user supplied a matching name/password pair by returning the user's information if the data are correct.
To understand an SQL injection attack, consider what would happen if the user supplied the specially-crafted string:
‘OR AGE>=0--
as the name and “any” as the password. The back-end logic will construct the query to the database as:
Query$=“SELECT*FROM USERS WHERE NAME=‘ ’OR AGE>=0--’ AND PASS=‘any’”
As it turns out, the “--” sequence denotes a comment in SQL, so the resulting query is interpreted as follows:
SELECT*FROM USERS WHERE NAME=‘ ’OR AGE>=0
This query will select all users from the USERS table where the user's name is equal to the empty string ‘ ’ OR where the user's AGE (another field in the database in this example) is greater than or equal to zero years old. Since every user is at least zero years old, this augmented query will select all users and return their results to the attacker.
By using the techniques illustrated in this example, the attacker can inject code to obtain access to credit card numbers and other confidential information, modify or delete information on the database, or perform other malicious actions. Thus, there is a need in the art for a way to detect malicious queries and prevent them from executing on the database.